NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/8507

Internet Message Format | 1996-08-05 | 1.8 KB

Path: keats.ugrad.cs.ubc.ca!not-for-mail
From: [e-mail] (Kazimir Kylheku)
Newsgroups: comp.lang.c
Subject: Re: Problem Negating an Unsigned Char
Date: 4 Mar 1996 11:23:57 -0800
Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: keats.ugrad.cs.ubc.ca

In article <[e-mail]>, Dik T. Winter <[e-mail]> wrote:
 >In article <[e-mail]> [e-mail] (Kazimir Kylheku) writes:
 >...
 > > >unsigned char a=0x11;
 > > >unsigned char b=0xEE;
 >...
 > > >    if( a == ~b ) {
 >...
 > > >The c remains unchange, while it changes to 1 if I cast the ~b to unsigned
 > > >char as if( a == (unsigned char) ~b )
 > >
 > > The cast forces the integer value of ~b into an unsigned char, stripping
 > > high-order bits. The above will work only on machines with eight bit chars.
 > >
 > > To make it portable, you must manually mask for the lower eight bits:
 > >
 > >     if (a == (~b & 0xff))
 >
 >And how would this work on machines with other than eight bit chars?
 >Casting to unsigned char will work regardless the number of bits in a char.

You are a fool. The poster obviously wants eight bit arithmetic, such that the
complement of 0xEE is guaranteed to be 0x11. Simply casting to unsigned char
will fail if you want portable eight bit arithmetic. On machines with eight bit
unsigned chars, the complement of 0xEE will be 0x11, as he apparently expects.
On machines with CHAR_BITS greater than eight, the complement of 0xEE is not
0x11 when cast to unsigned char.

Are you suggesting to this newsgroup that implementation-defined casts between
incompatible arithmetic types are more portable than using well-defined
bit operations?
--